hm2_eth: Xenomai4 OOB improvements - #4503
Conversation
|
@zz912 Can you test if this branch works on your setup? |
|
I commented: It works: |
Thanks for testing! |
|
The last commit should theoretically solve the issue when two boards are on the same Ethernet interface using a switch. By first sending reset and then switching all interfaces from OOB to Posix, there should be no issue if the same interface is used for two boards. It also removes some duplicated code. But I can not test two boards, I have only one. The way Xenomai4 is implemented, there is no error if you switch an interface twice to OOB or twice to Posix. Tested again with posix and evl including the error cleanup case. I call this ready. |
| //oob_enable_port needs: sockfd / server_addr / ip / ifname | ||
| //However, it must be called before the first ethernet | ||
| //communication in fetch_hwaddr. | ||
| ret = oob_enable_port(board); |
There was a problem hiding this comment.
If fetch_hwaddr() below fails here (board powered off, wrong IP), rtapi_app_main sets board_ip[i] = NULL, which makes cleanup() skip this board entirely. What state is the interface left in then, now that oob_enable_port() has already run? And what happens if the user retries afterwards with board_rtnet=posix on that same interface?
Would it make sense to call oob_disable_port() on any failure path after this point, so a failed init leaves nothing behind?
There was a problem hiding this comment.
Good catch. In this case, the port will stay in oob mode until:
evl net -di PORT- Reboot
- You run linuxcnc again with
board_rtnet=evl. This works, I tested this case already. board_rtnet=posixwill indeed fail to connect the board.
I need to look into it. There is a similar issue in the posix variant since probably forever, not all is cleaned up in this case but it won't have any noticeable side effect, just the socket is leaked.
There was a problem hiding this comment.
So, it should be fixed for posix and EVL. But I still have to test it tomorrow.
I found also an other bug in error handling I introduced in an old PR and fixed it.
There was a problem hiding this comment.
So, should be fine now. I found one other missed error case and improved a few messages.
Tested all error cases in posix and evl, all is cleaned up fine and no crash.
62bab83 to
9b9b247
Compare
By attaching rtapi_app also to the EVL core, no posix initialization is needed and all can be set up in rtapi_app_main(). Deprecate realtime-init, this function is not needed anymore.
This way, the specific network implementations don't have to know anything about the firewall.
This should avoid an issue with hm2_eth_net_evl when an interface is already set back to posix mode in close_board when an other instance is using the same interface to reset an other board. Also reduce duplicated code and improve reset message.
This is a bug introduced in LinuxCNC#4199. Restores the behaivour from before where a failed ifname resulted in a skipped install_firewall_perinterface but does continue. Additionally, add a warning. For OOB, ifname is mandatory to be able to switch the interface to OOB mode.
The socket was leaked and oob was not disabled.
9b9b247 to
9a871db
Compare
3 participants
While creating Xenomai3 support, a better way to do the initialization without needing to first use posix and then switch to OOB was discovered: By attaching also rtapi_app to the EVL core, OOB functions can also be used in rtapi_app_main.
This should have no side effects due to SCHED_WEAK is used for rtapi_app: https://v4.xenomai.org/core/user-api/scheduling/index.html#SCHED_WEAK. But it gets rid of the realtime-init function which is deprecated.
This PR also moves the firewall init / cleanup from the Ethernet implementations out to hm2_eth.c. This slightly alters the calling order but should have no side effects, simplifies the code and allows support library's with less shared symbols.
Tested:
Open:
Are there applications where multiple mesa cards are connected over a switch to a single Ethernet port? This might be an issue with the actual way of initializing the interfaces for Xenomai4. Different ports should work but I have no way of testing this due to I have only one card.Theoretically fixed. But I can not test it.